В 2018 году мы запустили один из крупнейших проектов в истории OVH: миграцию 3 миллионов веб-сайтов, размещенных в нашем центре обработки данных в Париже. Если вы хотите узнать причины этого титанического проекта, мы рассмотрели их в этом посте.

Пришло время объяснить, как мы продвигались в этом проекте. Мы уже говорили о наших эксплуатационных ограничениях, таких как обеспечение того, чтобы мы не влияли на веб-сайты, даже если мы не контролируем исходный код, и ограничение времени простоя. У нас также было много технических ограничений, связанных с архитектурой наших сервисов. Мы подробно рассмотрим наши различные сценарии миграции в следующей статье, а сегодня мы объясним, как работает инфраструктура, на которой размещены ваши веб-сайты.

Анатомия веб-хостинга

Для работы веб-сайтам и веб-приложениям обычно нужны две вещи :

• Исходный код, отвечающий за выполнение поведения веб-сайта
• T он данные , используемые в исходном коде , чтобы настроить опыт

Чтобы сайт работал , исходный код запускается на одном или нескольких серверах, среда которых настроена с помощью инструментов, связанных с используемыми языками программирования. В настоящее время PHP доминирует на рынке, но выбор не ограничивается этим языком.

Чтобы эти серверы оставались в рабочем состоянии, их необходимо обслуживать и обновлять, а их работу необходимо постоянно контролировать. Эта роль обычно отличается от роли разработчиков, которые несут ответственность за создание исходного кода веб-сайта. Если вас интересуют эти роли, мы рекомендуем узнать больше о системных администраторах и DevOps, а также об их конкретных навыках.

Для владельца веб-сайта мониторинг инфраструктуры и ее операций может быть очень дорогостоящим: вам нужна достаточно большая команда, чтобы поддерживать присутствие 24 часа в сутки, 365 дней в году. С такой командой разработчики могут полагаться только на разовые запросы на обслуживание, когда владелец веб-сайта хочет внести изменения.

Именно этот уровень управления мы предлагаем через наше решение для веб-хостинга. Вместо того, чтобы набирать команду системных администраторов для каждого веб-сайта, мы наняли команду технических экспертов, которые заботятся обо всех веб-сайтах, которые мы размещаем. То же самое и с данными, которые хранятся на определенных серверах и управляются теми же группами экспертов.

Таким образом, каждому веб-сайту не нужно использовать ресурсы всего сервера. С помощью наших решений мы объединяем ресурсы в нашей инфраструктуре, поэтому отдельные серверы могут использоваться для одновременного запуска нескольких веб-сайтов.

Все эти эффекты масштаба позволяют нам предлагать недорогие решения для веб-хостинга (от 1,49 евро в месяц), сохраняя при этом высокий уровень качества. Мы очень коротко объясним, как мы рассчитываем качество обслуживания, но если вы не хотите ждать, посмотрите конференцию, которую наши разработчики провели на FOSDEM 2019.

Чтобы достичь необходимого уровня качества при управлении таким количеством веб-сайтов, мы адаптировали нашу инфраструктуру.

Техническая архитектура наших решений для веб-хостинга

Классический подход к созданию службы веб-хостинга заключается в установке сервера, настройке баз данных и среды выполнения исходного кода, а затем размещении там новых клиентов до тех пор, пока сервер не заполнится, прежде чем переходить к следующему серверу.

Это очень эффективно, но у этого типа архитектуры есть некоторые недостатки :

• В случае поломки восстановление может быть долгим. Если у вас нет репликации системы в реальном времени, что очень дорого, вам нужно восстановить данные из резервной копии, а затем перенести их на новую машину, прежде чем повторно открывать службу для клиентов. Хотя вероятность аппаратного или программного сбоя невелика, это обычная операция в крупных инфраструктурах.
• Чтобы иметь дело с новыми технологиями, было бы предпочтительнее внедрять их на новых серверах только на первом этапе, а затем уделять время постепенному развертыванию их на существующих серверах на будущих этапах.
  Однако на таком быстро развивающемся рынке, как Интернет, становится трудно поддерживать разнородную инфраструктуру. Затем технические группы должны адаптироваться и работать с несколькими различными конфигурациями, что увеличивает риск регресса или поломки. А командам поддержки становится очень сложно запоминать все различные конфигурации и отслеживать текущие изменения.
• Каждый программный блок по своей сути сложен, поэтому для достижения максимальной производительности и качества обслуживания мы создали группы, специализирующиеся на каждой технологии: база данных, среда PHP, системы хранения, сеть… Может быть сложно заставить все эти группы взаимодействовать на одном сервере., и приводят к недопониманию относительно доступности веб-сайтов.
• Трудно выделить клиента, который потребляет больше ресурсов, чем в среднем. Если вам повезет, вы не будете на том же сервере, что и этот клиент, но если да, то производительность вашего веб-сайта может пострадать в результате потребления ресурсов.

Как вы можете видеть, в нашем масштабе, мы решили взять другой подход, в виде хорошо известного шаблона для приложений , которые должны иметь дело с нагрузкой : н- уровневой архитектуры .

N- уровневая архитектура

Участки с высоким уровнем нагрузки могут использовать п — уровень архитектуру, чтобы предоставить больше ресурсов для каждого программного кирпича, распределяя их между несколькими серверами. Если мы пойдем дальше с нашим разделением кода / данных, нам понадобится три сервера для запуска веб-сайта:

• Сервер, ответственный за выполнение исходного кода
• Два часто используемых сервера хранения : сервер базы данных и файловый сервер

Файловые серверы: Filerz

Это серверы, на которых мы храним файлы, составляющие веб-сайт (обычно исходный код веб-сайта). Они оснащены специальным оборудованием, обеспечивающим быстрый доступ к данным и надежность. Мы также используем специальную файловую систему ZFS, которая позволяет нам легко управлять локальным и удаленным резервным копированием.

Ими управляет специальная группа хранения, которая также предоставляет услуги этого типа нескольким другим командам в OVH (веб-хостинг, электронная почта…). Если вас это интересует, они также предлагают NAS-HA, который вы найдете в общедоступном каталоге наших выделенных серверов.

В случае сбоя мы сохраняем запас запчастей и серверов наготове, чтобы восстановить обслуживание как можно быстрее.

Серверы баз данных

Серверы баз данных обычно используются веб-сайтами для динамического размещения данных сайта. Они используют систему управления базами данных (СУБД) (MySQL с нашими решениями), которая структурирует данные и делает их доступными через язык запросов (в нашем случае SQL).

Эти серверы также требуют специального оборудования для хранения данных, особенно большого объема оперативной памяти, чтобы использовать преимущества систем кэширования СУБД и быстрее отвечать на поисковые запросы.

Этими машинами управляет специальная команда базы данных, которая отвечает за эту инфраструктуру. Команда базы данных предлагает эти услуги общественности через предложение CloudDB, а также обрабатывает частный SQL.

В Париже эти серверы размещены в частном облаке (SDDC), что позволяет переключать виртуальные машины на лету с одной физической машины на другую в случае возникновения проблем. Это помогает сократить время простоя во время обслуживания и время восстановления в случае отказа.

Веб-серверы

Это серверы, которые получают запросы и выполняют исходный код веб-сайта. Они получают свои данные из файлов и баз данных, предоставленных ранее описанными Filerz и серверами баз данных. Основное требование к этим серверам — хорошие ресурсы ЦП, необходимые для выполнения исходного кода.

Поскольку эти веб-серверы не имеют состояния (т.е. они не хранят никаких данных локально), можно добавить их больше и распределить нагрузку по нескольким машинам. Это позволяет нам распределять веб-сайты по разным серверам и избегать искажений при использовании в инфраструктуре, поскольку использование динамически распределяется по всем серверам фермы.

Если один из серверов выходит из строя, другие серверы в ферме доступны для поддержания трафика. Это позволяет нам использовать широкий спектр серверов, имеющихся в нашем инвентаре, при условии, что они имеют хорошие возможности ЦП.

Балансировка нагрузки

Запросы не приходят на предполагаемый веб-сервер по волшебству. Для этого вам нужна точка входа, которая отправляет запросы на правильный сервер. Эта технология называется «балансировкой нагрузки».

В нашем центре обработки данных в Париже есть серверы, оборудование которых полностью предназначено для балансировки нагрузки. Однако в нашей новой инфраструктуре Gravelines мы используем публичный кирпич: IPLB.

Трафик веб-сайта поступает на несколько IP-адресов ( docs.ovh.com/en/hosting/list-addresses-ip-clusters-and-web-hostings/#cluster-025 ), которые мы выделяем для нашей службы веб-хостинга.. Эти IP-адреса управляются нашими балансировщиками нагрузки. Следовательно, они являются отправной точкой нашей инфраструктуры. Кроме того, мы реализовали самые лучшие анти DDoS технологии, чтобы защитить веб — сайтов наших клиентов.

Эти нагрузки балансиры работают отлично для больших объемов трафика веб — сайта, распространение на нескольких веб — серверов, так как запросы распределяются справедливо, с помощью алгоритмов балансировки нагрузки. Но наши требования другие. Мы хотим иметь несколько различных сайтов на в одном сервере, и изменить распределение на основе нескольких критериев: хостинг пакет клиента (как более премиальные предложения включают меньше веб — сайтов на одном сервере), и ресурсы, необходимые для непрерывного распределения нагрузки.

Мы также предлагаем решения с гарантированными ресурсами, такие как Performance Hosting, или даже полностью выделенные, например Cloud Web.

Фактически, распределение нагрузки очень сильно привязано к нашим клиентам. Мы изменили систему распространения, добавив блок, предназначенный для OVH, с именем predictor, который выбирает веб-сервер в соответствии с веб-сайтом запроса. В предикторы адаптации к метрикам нашей инфраструктуры, и информация, предоставленная нашей системой.



Все это делает нашу инфраструктуру немного сложнее, чем обычно, хотя ж е не будет идти гораздо дальше в детали того, чтобы держать вещи простым и в рамках этого блога. Это должно было дать достаточно обзора, чтобы объяснить возможные сценарии миграции.

Благодаря добавлению балансировки нагрузки, а также нескольких серверов баз данных и файлового хранилища эта архитектура позволяет нам размещать невероятно большое количество различных веб-сайтов. Но, как знают все администраторы инфраструктуры, «дерьмо случается!». Рано или поздно случится сбой. Поэтому необходимо знать, как реагировать в таких случаях, чтобы минимизировать воздействие.

Домены сбоя

Один из методов уменьшения воздействия сбоев — ограничение их периметра путем создания доменов сбоя. За пределами мира информатики мы видим аналогичные концепции в управлении лесным хозяйством с использованием пустых участков в качестве противопожарных пробок или в строительной индустрии с дверями с тем же названием.

В нашем бизнесе речь идет о разделении инфраструктуры на части и распределении клиентов по разным кластерам. Поэтому мы разделили инфраструктуру Парижа на 12 идентичных кластеров. В каждом кластере мы находим балансировщик нагрузки, веб-серверы и Filerz. Я е один из кластеров идет вниз, « только « 1/12 из клиентов с сайтов, размещенных на этом центре обработки данных затронуты.

Серверы баз данных рассматриваются отдельно. Хотя мы не выделяем это как функцию, мы разрешаем нашим клиентам совместно использовать свои базы данных между своими хостинговыми решениями, когда им необходимо обмениваться данными. Поскольку клиент не может выбрать кластер своих веб-сайтов, мы отделили базы данных от кластеров, чтобы сделать их доступными для всего центра обработки данных.

Итак, в последний раз нам нужно обновить схему нашей инфраструктуры…

Управление инфраструктурой

Вся эта инфраструктура находится в ведении нашей информационной системы, с использованием конфигурации в режиме реального времени, которая формирует на связь между панелью управления OVH, в OVH API, и самой инфраструктурой.

Информационная система включает исчерпывающее представление инфраструктуры, что позволяет адаптировать доставку новых учетных записей, управлять изменениями в наших предложениях и выполнять технические действия с учетными записями.

Например, когда вы создаете новую базу данных в своем пакете хостинга, информационная система позаботится о выборе сервера, на котором она будет расположена, чтобы убедиться, что она создана в той же инфраструктуре, прежде чем уведомить вас о ее доступности по электронной почте или API.

Поздравляем… теперь вы знаете немного больше о нашей архитектуре! Чтобы узнать, где работает ваш собственный веб-сайт, вы можете найти имена серверов баз данных, Filerz и кластеров, связанных с вашим хостингом, в панели управления OVH.

Технические ограничения для миграции

Эта архитектура накладывает некоторые технические ограничения, если веб-сайты, размещенные на ней, будут продолжать работать по назначению:
 

• Все веб-сайты в одном кластере имеют один и тот же IP-адрес.
• Серверы баз данных и кластеры хостинга не коррелируют
• Чтобы перенести веб-сайт, вы должны синхронизировать его миграцию с миграцией всех связанных с ним элементов, то есть балансировщика нагрузки , Filerz и баз данных.
• Исходный код веб-сайта может использовать базу данных, на которую нет ссылок на его веб-хостинге.
• Исходный код может включать ссылки на инфраструктуру (абсолютная ссылка, включая номер файла , имя кластера, имя серверов баз данных ...)

Теперь вы знаете все операционные и технические ограничения, связанные с проектом миграции центра обработки данных. В следующей статье мы обсудим различные сценарии миграции, которые мы рассмотрели, и тот, который мы в итоге выбрали.

Вы переносили веб-сайт раньше? Если у вас есть или потребуется регулярно переносить веб-сайты, вы будете знакомы с трудностями, связанными с такого рода операциями.

Проще говоря, эта операция обычно включает шесть шагов:

• покупка и настройка инфраструктуры назначения
• тестирование новой инфраструктуры путем импорта данных и кода веб-сайта
• закрытие веб-сайта или перевод его в режим только для чтения, чтобы данные не сохранялись в старой инфраструктуре во время процесса миграции
• развертывание кода в новой инфраструктуре и импорт данных в новые базы данных
• изменение исходного кода для адаптации его к новой инфраструктуре (идентификаторы базы данных, подключение к внешним API и т. д.)
• после того, как веб-сайт будет работать над новой инфраструктурой, перенаправление трафика, чтобы снова сделать его доступным (изменение зон DNS, обновление серверной части балансировщика нагрузки и т. д.)

В зависимости от исходного кода веб-сайта и сложности инфраструктуры эти шаги могут различаться по сложности. На самом деле это зависит от доступа вашего веб-сайта к данным для записи. Следует ли хранить данные в базе данных? Есть ли на вашем сайте кеш на основе локальных файлов? Все это определено в исходном коде ваших веб-страниц.



Всего год назад, в марте 2018 года, OVH запустила крупный проект: перенос всех веб-хостингов и почтовых клиентов, размещенных в его устаревшем центре обработки данных в Париже, в новый центр обработки данных. Для организации проекта процесс миграции был разделен на две части, которыми управляют две отдельные группы: веб-хостинг для первой группы и электронная почта для второй. Сегодня мы сосредоточимся на миграции веб-хостинга, но команда миграции электронной почты также обсудит свой процесс в нашем техническом блоге.

Что касается веб-хостинга, то этот проект включает перенос трех миллионов различных веб-сайтов, размещенных на 7000 серверов в Париже. Некоторые из этих сайтов работают с 1999 года! Это одно из самых продолжительных направлений деятельности OVH. Так зачем же их мигрировать, если они прекрасно работают в Париже почти 20 лет? Чтобы понять все проблемы, с которыми мы сталкиваемся, нам нужно углубиться в историю этого сервиса.

Краткая история нашей платформы веб-хостинга

Когда Октав основал OVH в 1999 году, доступ в Интернет по-прежнему был ограничен. Первым направлением деятельности компании был хостинг сайтов. То, что сейчас кажется простым, в то время было не так просто. Вы должны были иметь хорошие сетевые соединения, поддерживать работу веб-серверов и правильно их настраивать. Было трудно найти людей, обладающих техническими знаниями или ресурсами для этого.

Строительство и расширение P19

В начале 2000-х у OVH была возможность приобрести здание в 19- м округе Парижа. У здания P19 был хороший доступ к электричеству и интернет-сетям, поэтому он мог предоставлять услуги веб-хостинга и электронной почты большому количеству клиентов. Некоторое время это был единственный центр обработки данных OVH.

В P19 OVH не просто предлагал веб-хостинг. В дата-центре также размещались выделенные серверы. Оба вида деятельности быстро завоевали популярность, и в конце 2000-х OVH начала строительство множества новых центров обработки данных в Рубе, затем в Страсбурге, Богарнуа (Канада), Гравелайн и других местах.

Каждый раз, когда мы строили новый центр обработки данных, мы набирались опыта, что помогало нам улучшать логистику и обслуживание. Эти новые центры обработки данных были намного больше, чем наша площадка в Париже, и дали нам пространство, необходимое для ускорения разработки многих инновационных технологий и решений, таких как водяное охлаждение, собственная производственная линия для серверов и стоек и система охлаждения для серверов. номера, в которых не было кондиционирования воздуха.

Как Интернет развивался с 1999 года по настоящее время

Интернет кардинально изменился с 1999 года. С нашей точки зрения, как хостинг-провайдер, мы наблюдали три изменения с течением времени…

• 1999 -> 2005: Рождение Интернета. Статические веб-сайты создавались в HTML. Именно тогда начали появляться блоги. Но эта технология была доступна только людям, которые знали, как использовать клиенты HTML и FTP, хотя FrontPage помог многим людям начать работу.
  Для работы эти веб-сайты включали данные прямо в код. Веб-хостинг был довольно простым: пользователю требовалось место для хранения и веб-сервер, единственной целью которого было отправить веб-страницу, которую он будет искать в пространстве для хранения.
• 2006 -> 2013: Web 2.0 — революция в социальных сетях и базах данных. Веб-сайты стали динамическими и могли отображать настраиваемые страницы в зависимости от пользователя. Именно тогда впервые начали появляться дискуссионные форумы, платформы для блогов и социальные сети, которые до сих пор так популярны.
  Динамические веб-сайты стали революцией для провайдеров веб-хостинга; код и данные теперь хранились в двух разных местах. Это означало, что страницу необходимо было создать до отправки конечному пользователю. Роль веб-сервера изменилась, и он будет генерировать эти страницы по запросу, в основном на языке PHP. Для этих веб-сайтов необходимо было добавить серверы баз данных, а также вычислительные мощности для веб-серверов.
• 2014 -> сегодня: JavaScript стал мощнее, помогая разработчикам создавать сложные веб-приложения в браузерах и значительно улучшая работу веб-пользователей. Это изменение стало возможным благодаря развертыванию Интернета на наших смартфонах. В результате может быть запущено большое количество сервисов, требующих доступа в Интернет.
  Технически это означает, что способы использования меняются, и пользователи чаще посещают веб-сайты, тем самым увеличивая объем создаваемых данных и сложность их обработки. Использование дискового пространства и ресурсов для создания веб-страниц постоянно увеличивается.

Мы очень быстро адаптировали наши решения к этим изменениям. Мы предложили новые базы данных, увеличили пространство для хранения, предоставили услуги CDN и многое другое.

Но быстрый рост числа пользователей и ресурсов для наших планов веб-хостинга заполнил наш центр обработки данных. В 2015 году мы заметили, что наш центр обработки данных в Париже будет заполнен к началу 2017 года из-за естественного роста сервиса и растущих потребностей веб-сайтов, которые мы размещаем.

Развертывание веб-хостинга в Gravelines

Как только мы это заметили, было только одно решение: чтобы избежать нехватки планов веб-хостинга, нам нужно разместить наши веб-сайты в другом центре обработки данных. Мы индустриализировали наши услуги в Париже, чтобы предоставлять услуги хостинга в режиме 24/7, управлять 7000 серверов и поддерживать их в рабочем состоянии на основе самых ранних технологий OVH.

Мы могли бы сохранить эту индустриализацию и применить ее к Gravelines, но мы решили сделать что-то еще. Мы решили создать новую техническую архитектуру, которая будет поддерживать растущие потребности с точки зрения производительности и, прежде всего, позволит нам повторно использовать другие продукты OVH. Это знаменитый подход « ешьте свою собачью еду », примененный и расширенный в масштабах наших планов веб-хостинга.

Мы поставили перед нашими собственными командами задачу управлять выделенными серверами, vRack (частная сеть), IP-адресами и балансировщиками нагрузки (IPLB), чтобы они могли поддерживать инфраструктуры и трафик наших клиентов. Став одним из крупнейших клиентов нашей компании, мы смогли выявить и преодолеть множество ограничений — повысить скорость отклика наших API, оптимизировать наши базы данных и многое другое.

Чтобы свести к минимуму задержки и соответствовать требованиям географического распределения, мы предлагаем нашим клиентам широкий выбор центров обработки данных по всему миру. Все эти центры обработки данных были потенциальными целями для роста нашей платформы. По причинам логистики мы решили запустить единственный новый центр обработки данных в Европе. И это не влияет на наши веб-сайты: различия в задержке между нашими центрами обработки данных настолько минимальны, что они даже не кажутся размещенными веб-сайтами (увеличение составляет всего несколько миллисекунд, а на это требуется несколько сотен). миллисекунды для создания веб-страниц).

Чтобы выбрать наш новый центр обработки данных, мы проанализировали естественный рост, чтобы удовлетворить потребности нашей инфраструктуры. Фактически, наша инфраструктура растет каждую неделю за счет поставок нового оборудования, и мы рисковали настолько быстро заполнить наши центры обработки данных, что это помешало бы нашим клиентам арендовать выделенные серверы и другие услуги OVH. Согласно этим критериям, только два центра обработки данных соответствовали нашим потребностям с точки зрения инфраструктуры в 2016 году: Gravelines в Северной Франции и Beauharnois в Канаде. Поскольку наша платформа в настоящее время развернута только в Европе, мы начали работать над Gravelines.

В то же время мы проанализировали и оптимизировали оборудование, используемое для построения наших кластеров, чтобы обеспечить более высокую производительность. Инновации, представленные в Gravelines, помогли нам еще больше повысить доступность нашей платформы.

Самой большой проблемой было не изменить опыт обслуживания — мы сохранили все функции и сохранили все те же графические интерфейсы и API. Нашей целью было просто обновить инфраструктуру, а не сами коммерческие продукты.

Этот центр обработки данных для веб-хостинга был открыт в июле 2016 года. А с ноября того же года все наши новые планы хостинга были доставлены туда.

Каждый год клиенты отменяют свои услуги веб-хостинга, потому что они больше не используют их, или переходят на другие продукты, такие как решения VPS. В результате за последние три года количество веб-сайтов, размещенных в Париже, постепенно уменьшалось. Это помогло нам справиться с увеличением мощности, необходимой для остальных веб-сайтов, без увеличения пропускной способности нашей инфраструктуры в Париже.

Учитывая естественное сокращение количества веб-сайтов, размещенных в центре обработки данных, мы решили, что лучше подождать, пока большинство наших клиентов откажутся от своих услуг, прежде чем мы их осуществим. Зачем это нужно, когда осталось три миллиона сайтов?

Почему мы решили перенести наш центр обработки данных?

Чтобы дать Парижу новую жизнь
Есть несколько причин, по которым мы начинаем это грандиозное предприятие. Но главная причина — это устаревание.

Наша инфраструктура основана на физических ресурсах, размещенных в этом центре обработки данных: выделенных и виртуализированных серверах (которые основаны на физических машинах), сетевых элементах и ​​контуре охлаждения (водяное охлаждение и кондиционирование воздуха). А для того, чтобы инфраструктура оставалась доступной 24/7, нам необходимо периодически обновлять это оборудование.

Для выделенных серверов все довольно просто. Если сервер выходит из строя, его можно просто заменить на новый. Серверы, построенные для Парижа, не имеют тех технических и логистических улучшений, которые приносят пользу другим нашим центрам обработки данных, и их становится все труднее собирать, поскольку устаревание нашего центра обработки данных требует от нас все больше и больше обновлять.

Мы рассмотрели возможность замены этих серверов моделями следующего поколения, но нам потребуется изменить архитектуру целых комнат. И чтобы добиться этого без какого-либо влияния на доступность нашей платформы, нам потребуется место для строительства новых комнат перед переносом серверов один за другим. В здании, которое почти полностью загружено, это потребует опустошения помещений.

Выделенным серверам для работы также требуются питание, сеть и система охлаждения. Все эти элементы также управляются физическим оборудованием: кондиционирование воздуха и водяное охлаждение для охлаждения машин, маршрутизаторы и переключатели для сети, электрические трансформаторы, устройства ИБП и батареи для электричества.

Эти избыточные физические инфраструктуры также необходимо регулярно заменять, чтобы избежать простоев. Если один путь доступа выйдет из строя, второй возьмет верх. Более того, это обычная операция, выполняемая техническими специалистами, поэтому они могут выполнять незначительные задачи по обслуживанию компонентов оборудования.

Процесс полной замены этих инфраструктур на новые долгий и сложный. Полагаться на единый путь доступа в течение такого длительного периода времени было просто невозможно. Для их замены потребуется настроить третий путь, а затем переключиться на него, когда все будет готово. Однако это также будет означать, что в центре обработки данных должно быть место для всех этих операций.

Спустя двадцать лет жизненный цикл нашего центра обработки данных в Париже подошел к концу. Требуются масштабные работы на всех уровнях, а для этого требуется пространство. Это основная причина миграции.

Для увеличения производительности сайта
Благодаря новой инфраструктуре Gravelines мы можем повысить производительность веб-сайтов наших клиентов. Более того, эти новые технологии помогли нам развернуть некоторые дополнительные функции, которые мы не можем развернуть в Париже без обновления нашей инфраструктуры: HTTP / 2, MySQL 5.6 и другие.

Наши клиенты могут сами перенести свои проекты, но миграция плана веб-хостинга — сложная и деликатная процедура. Многие клиенты отказались от этого.

После завершения миграции мы также сможем упростить наше оперативное обслуживание, используя исключительно стандарты OVH. Это поможет нам избежать выполнения определенных операций в центре обработки данных в Париже, сократив время обслуживания и риски некоторых повторяющихся ручных операций.

Как мы переносим так много сайтов?
Как провайдер веб-хостинга, мы в основном специализируемся в двух областях: размещение данных и выполнение кода.

Хостинг данных — сложная операция, если необходимо поддерживать ее целостность с течением времени, но это относительно стандартизированная отрасль. Данные хранятся в файловой системе (это стандарт) или в базе данных, использующей определенный язык запросов (MySQL 5.5 или MySQL 5.6). Поэтому нам просто нужно воспроизвести архитектуру, отвечающую тому же стандарту в целевой инфраструктуре, и перенести в нее данные.

Выполнение кода более сложное. Очень сложно сделать вывод о поведении исходного кода в его среде, по крайней мере, не интерпретируя его. Он может возвращать ошибку в конкретной версии расширения PHP, проверять наличие локальной папки и многое другое. Например, многие наши клиенты хранят в коде абсолютный путь к своим файлам. Однако это означает, что мы не можем изменить место хранения файлов без ущерба для их обслуживания.

Когда вы размещаете услуги для нескольких клиентов, вы можете легко помочь им, обнаружив коды, которые больше не будут работать после миграции. Но в более широком масштабе это сложно. Представьте, что вы делаете это с кодами более трех миллионов веб-сайтов!

Просить наших клиентов изменить их исходный код было нежизнеспособным решением. Даже если предположить, что все наши клиенты прочтут электронное письмо об этом, некоторые из них не будут вносить изменения из-за нехватки времени, технических знаний или просто забыли сделать это. Мы будем создавать проблемы для наших клиентов с их веб-сайтами, а для нас это просто не вариант.

Почти год мы разработали несколько сценариев миграции. Мы экстраполировали их по всем направлениям, преследуя две цели:

• веб-сайты должны оставаться работоспособными после завершения миграции, при этом клиентам не нужно вносить какие-либо изменения в свой код.
• влияние на доступность сервиса в процессе миграции должно быть минимальным

Мы реализовали и протестировали некоторые из этих сценариев в период с марта по июнь 2018 г. Эта первоначальная работа помогла нам выбрать лучший план миграции. Чтобы завершить эту миграцию, не затрагивая службы, нам нужно было адаптировать часть нашей инфраструктуры и информационной системы: создать сетевой туннель между центрами обработки данных, изменить балансировщики нагрузки, нашу платформу базы данных, добавить прокси-серверы SQL и многое другое.

Мы тщательно протестировали выбранный сценарий. Чтобы гарантировать, что эта процедура будет выполнена с минимальным воздействием, мы многократно повторили ее в реальных условиях на внутренних кластерах, используя наборы данных, основанные на производственных платформах.

Хотите узнать больше о нашем плане миграции? Мы не можем включить все в это сообщение в блоге, поэтому мы решили рассказать о нашей миграции в серии сообщений, поскольку тема очень обширна.

Следите за нашими предстоящими публикациями, которые дадут вам закулисное представление о самом крупномасштабном переносе веб-сайтов, осуществленном крупнейшим хостинг-провайдером Европы!